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(57) A method of processing a remote procedure 
call from a client computer to an object stored on an ag- 
gregation of server computers includes the step of 
checking a server aggregation location data field and a 
server aggregation contact strategy data field of the re- 
mote procedure call. The aggregation of server comput- 



ers is designated as replicating server computers, mi- 
grating server computers, or federated server comput- 
ers based upon the checking operation. Once a server 
computer aggregation topology is identified, parameters 
associated with the remote procedure call may be mod- 
ified to alter the interaction with the server computer ag- 
gregation. 
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D s ripti n 

Brief Description of the Invention 

This invention relates generally to aggregations of 
server computers that collaborate to provide a service 
in distributed client-server computer systems. More par- 
ticularly, this invention relates to a technique of interact- 
ing with an aggregation of server computers based upon 
a derived characterization of the server computer ag- 
gregation. 

Background of the Invention 

In a client/server computer network, the user of a 
client computer requests the execution of an object. In 
particular, the user requests the execution of a method 
associated with the object. Frequently, the object is not 
stored locally on the client computer. Thus, a remote 
procedure call (RPC) must be made to a server compu- 
ter on which the object resides. In most cases, the server 
computer executes the requested method to generate 
a result. The result is then passed to the client computer. 

It is common to provide an aggregation of server 
computers that collaborate to supply a service to client 
computers. This collaboration of server computers may 
be referred to as server aggregation. Reasons to use 
server aggregation include: robustness and fault-toler- 
ance, load-balancing, data partitioning, allowing for sys- 
tem evolution (upgrades, etc.), priority and secure serv- 
icing, etc. The development of almost any mission-crit- 
ical application makes use of some form of aggregation, 
and thus it is important that any distributed application 
develop a framework that provides support for it. 

Figure 1 illustrates a client/server computer appa- 
ratus 20 in accordance with the prior art. The apparatus 
20 includes a set of client computers 22A-22N, which 
are each linked to a transmission channel 23. The trans- 
mission channel 23 generically refers to any wire or 
wireless link between computers. The client computers 
22A-22N use the transmission channel 23 to communi- 
cate with a set of server computers 24A-24N, forming a 
server aggregation 25. 

Each client computer 22 has a standard computer 
configuration including a central processing unit (CPU) 
30, connected to a memory 32, which stores a set of 
executable programs. The executable programs in this 
exemplary system include at least one client application 
program 34, client stubs 38, client subcontracts 40, and 
an operating system 42. 

The client application program 34 is any applica- 
tion-level program, such as an application program that 
the user of a client computer 22 interacts with. The client 
stubs 38 receive procedure calls by the application pro- 
gram 34 requesting the execution of specified methods 
of specified objects. The purpose of the client stubs 38 
is to access objects that are implemented in other ad- 
dress spaces, such as at the server computers 24A- 
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24N. 

The client subcontract programs 40 and s rver sub- 
contract programs 58 control the basic mechanisms of 
object, invocation and argument passing. Th y control 
s how object invocation is implemented, how object refer- 
ences are transmitted between address spaces, how 
object references are released, and similar object runt- 
ime operations. For example, when a client invokes an 
object of a given subcontract, the subcontract imple- 
10 ments the object invocation by transmitting the request 
to the address space where the associated object is lo- 
cated, commonly a server computer 24 of the server ag- 
gregation 25. 

The client subcontract programs 40 perform a mar- 
15 shal operation to transmit an object invocation (i.e., a 
remote procedure call) to another address space. A cor- 
responding un-marshalling operation is performed by a 
server subcontract 58 on a server computer 24. The cli- 
ent subcontract programs 40 also perform unmarshal 
20 operations when receiving a reply (such as the results 
generated from a method call) from another computer, 
say the server computer 24. An operating system 42 un- 
derlies the operations of the client application programs 
34, the client stubs 38, and the client subcontracts 40. 
25 Each server computer 24 has a configuration anal- 
ogous to that of each client computer 22. Each server 
24 includes a CPU 50 and an associated memory 52. 
The memory 52 stores server application programs 54, 
server stubs 56, server subcontract programs 58, and 
30 an operating system 60. As indicated above, the server 
stubs 56 handle incoming method invocations on an ob- 
ject and call the specified method to perform the oper- 
ation. As also indicated above, the server subcontracts 
58 perform data marshalling and other operations to 
35 support the transport of method invocations and the re- 
sulting return messages between the server 24 and the 
client computers 22. 

The operations of the apparatus of Figure 1 ar 
more fully appreciated with reference to Figure 2. 
40 Figure 2 illustrates the client computer 22A, the trans- 
mission channel 23, and the server computer 24A. As 
indicated above, a client application 34 invokes a spec- 
ified method of an object in a different address space 
using a remote procedure call. The remote procedure 
45 call is passed by the client stubs 38 to the client subcon- 
tract 40, which packages the remote procedure call for 
transport on the transmission channel 23. The server 
subcontract 58 of the server 24A receives the informa- 
tion and un-packages it. The server subcontract 58 then 
so passes the information to the server stubs 56. The serv- 
er stubs 56 access the server application programs 54, 
which are the previously described object methods. 
More specifically, a specified server stub 56 makes a 
procedure call to execute a specified method of the in- 
55 voked object. The execution of the method produces a 
set of results, herein called a reply, which is then passed 
back to the server subcontract 58 and the communica- 
tion path is reversed, as indicated by the.arrows of Fig- 
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ure 2. 

Block 70 of Figure 2 illustrates the components as- 
sociated with an Object Request Broker (ORB). An ORB 
is a distribut d mechanism tor handling remote proce- 
dure calls. The mechanism is distributed in the sense 
that the software associated with an ORB is on both the 
client computer 22 and the server computer 24. 

The present invention is directed toward a distribut- 
ed object client/server computer system of the type de- 
scribed in relation to Figures 1 and 2. More particularly, 
the invention is directed toward the operation of a server 
computer aggregation 25 in a distributed object client/ 
server computer system. Existing server computer ag- 
gregations lack a common architectural basis that can 
be used to provide clean and elegant implementations 
of server aggregation features. The absence of a com- 
mon architectural basis for server aggregation features 
prevents a reasonably uniform view for both system us- 
ers and administrators. Thus, it would be highly desira- 
ble to provide a clean and elegant implementation of 
server aggregation features. Such an implementation 
would provide a reasonably uniform systematic ap- 
proach for both system users and administrators. 

Summary of the Invention 

An embodiment of the invention includes a method 
of processing a remote procedure call from a client com- 
puter to an object stored on an aggregation of server 
computers. A server aggregation location data field and 
a server aggregation contact strategy data field of the 
remote procedure call are checked. The aggregation of 
server computers is designated as replicating server 
computers, migrating server computers, or federated 
server computers based upon the checking operation. 
Once a server computer aggregation topology is identi- 
fied, parameters associated with the remote procedure 
cal I may be modified to alter the interaction with the serv- 
er computer aggregation. 

The invention's identification and use of server ag- 
gregation topology information provides a clean and el- 
egant implementation for server aggregation features. 
In addition, the server aggregation topology information 
provides a reasonably uniform and systematic approach 
for both system users and administrators. 

Brief Description of the Drawings 

Examples of the invention will be described in con- 
junction with the accompanying drawings, in which: 

FIGURE 1 illustrates a prior art client/server com- 
puter system with a server computer aggregation. 

FIGURE 2 illustrates the handling of remote proce- 
dure calls in the system of Figure 1. 

FIGURE 3 illustrates processing operations associ- 
ated with a client computer accessing a server computer 
aggregation with a dual-role proxy, in accordance with 
an embodiment of the invention. 



FIGURE 4jllustrates processing operations associ- 
ated with a client computer accessing a server cornput r 
aggregation with a dual-role proxy, in accordance with 
an embodiment of the invention. 
5 FIGURE 5 illustrates processing operations associ- 

ated with a client computer accessing a server computer 
aggregation with a dual-role proxy, in accordance with 
an embodiment of the invention. 

FIGURE 6 illustrates processing operations associ- 
io ated with a client computer accessing a server comput r 
aggregation with a dual-role proxy, in accordance with 
an embodiment of the invention. 

FIGURE 7 illustrates an aggregation object refer- 
ence data structure utilized in accordance with an em- 
is bodiment of the invention. 

FIGURE B illustrates a server computer configured 
in accordance with an embodiment of the invention. 

FIGURE 9 illustrates a client computer configured 
in accordance with an embodiment of the invention. 
20 FIGURE 1 0 illustrates a server aggregation charac- 
terization technique utilized in accordance with an em- 
bodiment of the invention. 

Like reference numerals refer to corresponding 
parts throughout the several views of the drawings. 

25 

Detailed Description of the Preferred Embodiment 

In the system of Figure 1 , a client computer, say cli- 
ent computer 22A, contacts the aggregation of server 
50 computers 25 by initially contacting a primary server, 
say server computer 24A. More particularly, a client 
computer, say client computer 22A, generates a remote 
procedure call to an object stored on a primary server, 
. say server computer 24A. (In the following discussion it 
35 is understood that a reference to a client computer 22 
contacting a server computer 24 contemplates a remote 
procedure call from the client computer 22 to the server 
computer 24.) After the client computer accesses the 
primary server, other server computers, say server com- 
^0 puters24Band24C, in the aggregation 25 are then con- 
tacted by the client computer 22A. 

The present embodiment departs from the ap- 
proach described in reference to Figure 1 . In particular, 
the embodiment utilizes a dual-role smart proxy server 
45 computer as a gateway to an aggregation of server com- 
puters. This operation can be appreciated with refer- 
ence to Figure 3. 

Figure 3 illustrates a client computer 22A and a 
server computer aggregation 25 including server corn- 
so puters 24A-24N. In accordance with the invention, the 
server computer aggregation 25 includes three types of 
server computers: a dual-role proxy server computer 
24A, a primary server computer 24B, and a set of sec- 
ondary server computers 24C-24N. 
55 The client computer 22A initially contacts the dual- 
role proxy server computer 24A. Thereafter, the dual- 
role proxy server computer 24A contacts the remaining 
server computers 24B-24N of the aggregation 25. Thus, 
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in this embodiment of the invention, the dual-role proxy 
server comput r 24 A operates as a front-end server 
computer for the server aggregation 25. 

The dual-role proxy server computer 24A performs 
this operation for client computers that are not clients of 
the aggregation 25. In other words, a client computer is 
involved, but the client computer is a non-client of the 
server aggregation 25, meaning it has substantially lim- 
ited knowledge and access to the server aggregation 
25. 

Figure 4 illustrates a server aggregation 25 being 
accessed by an aggregation client server computer 
22B. The aggregation client server computer 22B has 
substantial knowledge and access to the server aggre- 
gation. As a result, it can bypass the dual-role proxy 
server computer 24A and directly contact the primary 
server 24B and secondary servers 24C-24N. This ap- 
proach is feasible when server aggregation information 
can be statically determined and embedded in an object 
reference. 

Server aggregation information is not always static. 
Frequently, the location of servers is dynamically con- 
figurable and updated. In this case, it is necessary for a 
client computer to obtain this dynamic information. 

Figure 5 illustrates a processing sequence that can 
accomplish the required update of dynamic information 
for a client computer. Figure 5 illustrates a client com- 
puter 22B directly accessing a primary server 24B, as 
shown with arrow 60. The primary server 24B then pass- 
es dynamic information back to the aggregation client 
computer 22B, as shown with arrow 62. With the updat- 
ed dynamic information, the aggregation client compu- 
ter 22B may then directly access the secondary servers 
24C-24N, as shown with arrows 64 and 66. Note once 
again that the dual-role proxy computer 24A is by- 
passed. 

. Fault-tolerant behavior in a server aggregation 25 
requires the aggregation client computer 22Bto be able 
to communicate with the servers in the aggregation 
even if the primary server 24B is unavailable. In this 
case, the dual-role proxy server 24A may be exploited. 

Figure 6 includes an arrow 60 representing the ag- 
gregation client computer 22B attempting to contact the 
primary server 24B. If the primary server 24B is inoper- 
ative, then the aggregation client computer 22B con- 
tacts the dual-role proxy server 24A, as shown with ar- 
row 72. The dual-role proxy server 24 A responds by 
passing updated aggregation information back to the 
aggregation client computer 22B, as shown with arrow 
74. Thereafter, the aggregation client computer 22B can 
directly access the secondary servers 24C-24N, as 
shown with arrows 76 and 78. 

It can now be appreciated that the dual-role proxy 
server computer 24A of the invention performs two 
roles. First, it operates as a server aggregation gateway 
for non-client server computers. Second, it operates as 
an information agent for client server computers. 

The operation of an embodiment of the invention 



has now been described. Attention presently turns to a 
discussion of different techniques that may be used to 
implement the invention. 

Figure 7 illustrates an aggregation object reference 

5 data structure (AORDS) 80 that may be used in accord- 
ance with the invention. Each AORDS 80 includes loca- 
tion information for the smart proxy server of the server 
aggregation. In addition, each AORDS includes an ob- 
ject key, including a server aggregation location and a 

10 server aggregation contact strategy. The server aggre- 
gation location information includes a field for the loca- 
tion information for the primary server and a field for the 
location information for the secondary servers. Finally, 
each AORDS includes a client key, which stores infor- 
ms mat ion that identifies whether the object associated with 
the AORDS is a server aggregation client. 

A non-client of a server aggregation will have miss- 
ing fields in the AORDS data structure. In other words, 
a remote procedure call associated with a non-client of 

20 a server aggregation will have information regarding the 
location of the smart proxy server, will have client key 
information indicating a non-client status, but will not 
have, or will have incomplete, object key information. As 
indicated above, the object key information includes 

25 server aggregation location information and server ag- 
gregation contact strategy information. The dual-role 
proxy server is relied upon by the non-client to have the 
primary server location information and the secondary 
servers location information and to effectuate commu- 

30 nications with those servers. 

A client of a server aggregation will have complete 
fields in the AORDS data structure. That is, smart proxy 
server location information will be available, client key 
information (indicating status as a client) will be availa- 

35 ble, and object key information will be available, namely 
location information for the primary server and location 
information for the secondary servers, and a server ag- 
gregation contact strategy. While the information may 
be complete, it may have to be periodically updated, as 

40 described in reference to Figures 5 and 6. 

Figure 7 illustrates that the AORDS data structure 
may be handled, along with other method call data, by 
client subcontracts 40 on the client computer side of the 
client/server system. As indicated in the background 

45 section, a client application program 34 generates a re- 
mote procedure call. Thereafter, client stubs 38 operate 
as an interface to a client sub-contract 40. The client 
sub-contract 40 is used to transport the remote proce- 
dure call over a transmission channel. Reverse process- 

50 jng is then performed at the server side. The general 
handling of object data structures in an object request 
broker of a distributed client/server system is known in 
the art. 

Figure 8 illustrates a server computer 90 in accord- 
55 ance with an embodiment of the invention. The server 
computer 90 includes a CPU 92 connected to a memory 
94, which stores a set of executable programs. Figure 
8 illustrates server applications 96, including a client key 
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interpreter 98. The client key interpreter 98 interprets 
the client key field of the AORDS 80. In other words, the 
client key interpreter 98 determines whether a remote 
procedure call is associated with a server aggregation 
client. 

A server aggregation gateway module 100 is also 
stored in the memory 94. The server aggregation gate 
module 100 includes the logic for accessing the primary 
servers and secondary servers of the server aggrega- 
tion when a non-client remote procedure call is being 
processed. 

Another application stored in the memory 94 of the 
server computer 90 is an aggregation update module 
102. As its name implies, this executable program pro- 
vides updated information on the server aggregation. 
This module is invoked, for example, during the 
processing shown in Figure 6. 

Figure 8 also illustrates server stubs 104 stored in 
memory 94. Server subcontracts 106 are also stored in 
memory 94. The server subcontracts 106 handle the 
previously described AORDS 80. The memory 94 also 
includes an operating system 108. 

The AORDS concept disclosed in accordance with 
an embodiment of the invention is highly beneficial be- 
cause it supports the invention's concept of a dual-role 
proxy server computer. The concept finds further utility 
in its role of identifying different types of server aggre- 
gations. In other words, in accordance with another em- 
bodiment of the invention, the AORDS information is 
scrutinized to determine what type of server aggregation 
is being invoked by a remote procedure call. This infor- 
mation can then be used to change selected parameters 
associated with the remote procedure call. 

This operation is more fully appreciated with refer- 
ence to Figure 9. Figure 9 illustrates a client computer 
110 operated in accordance with an embodiment of the 
invention. The client computer 110 includes a CPU 112 
and a memory 114. The memory 114 stores a set of ex- 
ecutable programs including client application programs 
116. The client application programs 116 include an ag- 
gregation parameter check module 118. The aggrega- 
tion parameter check module 118 checks the server ag- 
gregation location data field and the server aggregation 
contact strategy data field of the AORDS 80. Based up- 
on this operation, the nature of the server aggregation 
25 is determined. 

Figure 10 illustrates the different types of server ag- 
gregation topologies that are recognized in accordance 
with the invention. If the server aggregation location is 
known to the client computer (and its associated remote 
procedure calls) and the server aggregation contact 
strategy is also known to the client computer (and its 
associated remote procedure calls), then a replicating 
server aggregation is said to exist. A replicating server 
aggregation is one in which multiple servers maintain 
synchronized and consistent information. Thus, multiple 
clients can independently access replica s rvers for the 
same information. 
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It is impractical to expect a client to know the loca- 
tion of a server aggregation, yet not know the strategy 
to contact the server aggregation, thus the lower left cor- 
ner of the box of Figure 10 is crossed out. 
s Another server aggregation topology that is recog- 

nized in accordance with the invention is a migrating 
server aggregation. A migrating server aggregation ex- 
ists when the client computer has a contact strategy (the 
server aggregation contact strategy of the AORDS 80), 
10 but does not have the server aggregation location (th 
server aggregation location of the AORDS 80). Most 
common scenarios of migration have the client compu- 
ter 22 contacting the primary server and being forward- 
ed to the new location of the server. Thus, the client com- 
75 puter knows the strategy (i.e. following the forwarding 
pointer), but not the location of the new server. 

The final server aggregation topology that is recog- 
nized in accordance with the invention is a federated 
server aggregation. For this topology, the server aggre- 
20 gation location is known to the server and the contact 
strategy is located with the server, as shown in Figure 
10. Almost all cases of federation involve the primary 
server knowing both the locations of the other servers 
in the federation as well as the logic for interacting with 
25 them and building a response. 

The aggregation designator 120 is an executable 
program that checks the server aggregation location 
field and the server aggregation contact strategy field of 
the AORDS 80 of the invention. Based upon the infor- 
30 mation it observes, it provides a designation to the serv- 
er aggregation, pursuant to the framework shown in Fig- 
ure 10. 

Thus, the present invention uses the server aggre- 
gation location information and server aggregation con- 
35 tact strategy of the AORDS 80 to identify a server ag- 
gregation topology. These information fields represent 
two critical bits of control that determine the different 
kinds of interaction between a client and an aggregation 
of servers. In accordance with the embodiment one may 
40 structure the implementation of server aggregation fea- 
tures around these two pieces of information, providing 
a select set of strategies that can be employed for inter- 
acting with the servers in the aggregation. This advan- 
tage also applies to administrative interfaces. 
45 A remote procedure call processor 122 may be 
used to alter parameters associated with a remote pro- 
cedure call once the server aggregation topology is 
identified. For example, if a replicating server aggrega- 
tion is identified, the RPC processor 122 may be used 
so. to prefetch a list of replica servers that can respond to 
the same method call. In this case, if a client computer 
fails in its initial attempt to contact a server, the client 
computer immediately accesses the pre-f etched list of 
replica servers that can respond to the method invoca- 
55 tion. 

After a migrating server aggregation is identified, 
the RPC processor 122 may be used to set parameters 
that limit the number of migrations that can be performed 
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to satisfy a method call. 

Another example of how the RPC processor 1 22 
may respond to the aggregation designation is to set 
context flags associated with the method call. For in- 
stance, the context flags may be used to determine 
which requests are propagated to the federation and 
which are necessarily serviced by the primary server on- 
ly. 

Figure 9 also illustrates a set of client stubs 124 of 
the type previously described. Figure 9 also illustrates 
client subcontracts 126 that handle the disclosed 
AORDS 80. Finally, Figure 9 illustrates a operating sys- 
tem 128 associated with the client computer 110. 



Claims 

1. A client/server computer apparatus, comprising: 

a transmission channel; 
an aggregation of server computers connected 
to said transmission channel; and 
a client computer connected to said transmis- 
sion channel, said client computer executing 

af irst routine to check a server aggregation 
location data field and a server aggregation 
contact strategy data field of a remote pro- 
cedure call generated by said client com- 
puter, and 

a second routine to designate said aggre- 
gation of server computers as replicating 
server computers, migrating server com- 
puters, or federated server computers 
based upon the result of said first routine. 

2. The apparatus of claim 1 wherein said first routine 
designates said aggregation of server computers 
as replicating server computers when said server 
aggregation location data field is complete and said 
server aggregation contact strategy data field is 
complete. 

3. The apparatus of claim 1 wherein said first routine 
designates said aggregation of server computers 
as migrating server computers when said server ag- 

.. gregation location data field is incomplete and said 
server aggregation contact strategy data field is 
complete. 

4. The apparatus of claim 1 wherein said first routine 
designates said aggregation of server computers 
as federated server computers when said server 
aggregation location data field is incomplete and 
said server aggregation contact strategy data field 
is incomplete. 

5. The apparatus of claim 1 wherein said client com- 



puter executes a third routine to modify a remote 
procedure call parameter after said aggregation of 
server computers is designated. 

5 6. Acomputer readable memory storing executable in- 
structions for execution by a client computer of a 
client/server computer system including an aggre- 
gation of server computers, comprising: 

a plurality of instruction sets stored, in said 

to computer readable memory, including 

a first instruction set to check a server aggre- 
gation location data field and a server aggrega- 
tion contact strategy data field of a remote pro- 
is cedure call generated by said client computer; 

and 

a second instruction set to designate said ag- 
gregation of server computers as replicating 
server computers, migrating server computers, 
20 orfederated server computers based upon said 

check operation of said first instruction set. 

7. The computer readable memory of claim 6 wherein 
said first instruction set includes instructions todes- 

2S ignate said aggregation of server computers as rep- 
licating server computers when said server aggre- 
gation location data field is complete and said serv- 
er aggregation contact strategy data field is com- 
plete. 

30 

8. The computer readable memory of claim 6 wherein 
said first instruction set includes instructions to des- 
ignate said aggregation of server computers as mi- 
grating server computers when said server aggre- 

35 gation location data field is incomplete and said 
server aggregation contact strategy data field is 
complete. 

9. The computer readable memory of claim 6 wherein 
40 said f i rst instruction set includes instructions to des- 
ignate said aggregation of server computers as fed- 
erated server computers when said server aggre- 
gation location data field is incomplete and said 
server aggregation contact strategy data field is in- 

4S complete. 

10. The computer readable memory of claim 6 further 
comprising a third instruction set to modify a remote 
procedure call parameter after said aggregation of 

so server computers is designated. 

11. A method of processing a remote procedure call 
from a client computer to an object stored on an ag- 
gregation of server computers, said method com- 

55 prising the steps of: 

checking a server aggregation location data 
field and a server aggregation contact strategy 



30 

8. 



6 



11 



EP 0 817 445 A2 



12 



data field of said remote procedure call; and 
designating said aggregation of server comput- 
ers as replicating server computers, migrating 
server computers, or federated server comput- 
ers based upon said checking step. 

12. The method of claim 11 wherein said designating 
step includes the step of designating said aggrega- 
tion of server computers as replicating server com- 
puters when said server aggregation location data 
field is complete and said server aggregation con- 
tact strategy data field is complete. 

13. The method of claim 11 wherein said designating 
step includes the step of designating said aggrega- 
tion of server computers as migrating server com- 
puters when said server aggregation location data 
field is incomplete and said server aggregation con- 
tact strategy data field is complete. 

14. The method of claim 11 wherein said designating 
step includes the step of designating said aggrega- 
tion of server computers as migrating server com- 
puters when said server aggregation location data 
field is incomplete and said server aggregation con- 
tact strategy data field is incomplete. 

15. The method of claim 11 further comprising the step 
of processing remote procedure call information in 
response to said designating step. 

16. The method of claim 15 wherein said processing 
step includes the step of modifying a remote proce- 
dure call parameter in response to said designating 
step. 

17. The method of claim 15 wherein said processing 
step includesthe step of compiling client/server sta- 
tistics in response to said designating step. 

1 8. A method executed by a client computer under the 
control of a program, said client computer being 
connected to an aggregation of server computers, 
said client computer including a memory storing 
said program, said method comprising the steps of: 

generating at said client computer a remote 
procedure call to said aggregation of server 
computers; 

checking a server aggregation location data 
field and a server aggregation contact strategy 
data field of said remote procedure call; and 
designating said aggregation of server comput- 
ers as replicating server computers, migrating 
server computers, or federated server comput- 
ers based upon said checking step. 

19. The method of claim 18 wherein said designating 



step includes the step of designating saidaggr ga- 
tion of server computers as replicating server com- 
puters when said server aggregation location data 
field is complete and said server aggregation con- 
5 tact strategy data field is complete. 

20. The method of claim 18 wherein said designating 
step includes the step of designating said aggrega- 
tion of server computers as migrating server com- 

io puters when said server aggregation location data 
field is incomplete and said server aggregation con- 
tact strategy data field is complete. 

21. The method of claim 18 wherein said designating 
is step includes the step of designating said aggrega- 
tion of server computers as migrating server com- 
puters when said server aggregation location data 
field is incomplete and said server aggregation con- 
tact strategy data field is incomplete. 

20 

22. The method of claim 1 8 further comprising the step 
of processing remote procedure call information in 
response to said designating step. 

2S 23. The method of claim 22 wherein said processing 
step includes the step of modifying a remote proce- 
dure call parameter in response to said designating 
step. 

30 24. The method of claim 22 wherein said processing 
step includes the step of compiling client/server sta- 
tistics in response to said designating step. 
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